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Abstract. Emergency management is represented by managerial functions 
which aim to reduce vulnerability to hazards and to cope with disasters. 
Emergencies often have direct impact on the environment. This paper focuses 
on identification and subsequent software support processes in the emergency 
management. The paper aims to describe a process methodology for emergency 
management in details. The methodology describes how to manage an 
information system development suitable for emergency management, which is 
built on business processes. The methodology consists of five main phases. 
Each phase is described in terms of individual activities, work products, and 
user roles. The next part of the paper recommends the use of particular 
technologies, tools and resources that have been successfully proved in the 
analysis of emergency situations in the Czech Republic. The straightforward 
outcome of the novel process methodology is more effective solution of 
emergency situations and therefore the reduction of negative environmental 
impacts. 

Keywords: Process Management, Emergency Management, Process 
Methodology, Recommendations. 


1 Introduction 

The emergency management requires considerable effort. To manage emergencies, it 
is necessary to spend human resources and also technical resources. It is useful if 
there are available some best practices in solving the emergencies, and also specified 
responsibilities for particular activities. To capture such information it is appropriate 
to use the process management, which has been approved in the private and public 
sector [3]. 

Identification and subsequent automation of the process is a challenging issue. At 
present, there are primarily two different approaches to the business process 
deployment. The first approach is based on the business process life-cycle, the second 
one on the overall architecture which supports the business process deployment. Both 
of these approaches are supported by the multinational corporation (Object 
Management Group and Workflow Management Coalition), which enforces standards 
in this field. 

It is convenient to integrate the above mentioned approaches to the process 
management for effective process deployment and create a common framework for 



an unified view of the process deployment. Such a view is defined by Process 
Framework for Emergent Management that takes into account specific factors relating 
to the emergency management [4]. 

The Process Framework for Emergency Management provides a basic view of the 
process deployment from the methodology and architecture point of view. For this 
reason, this paper aims to describe the process-oriented methodology in detail, which 
is an essential part of the framework. 


2 Methodologies Based on Business Process 

There are many methodologies that lead the user through the process deployment, e.g. 
Object Process Methodology, Rationed Unified Process, Methodology for Modelling 
and Analysis of Business Process or Business Driven Development. The business 
process analysis is the principle of these methodologies, but the process automation of 
does not follow the process management ideology. The next part of the paper briefly 
describes the methodologies and also shows their disadvantages. 


2.1 Object Process Methodology 

Object Process Methodology (OPM) [1] is an approach to designing information 
systems by depicting them using object models and process models. OPM combines a 
minimal set of building blocks with a dual graphic-textual representation in a single 
diagram type. This makes OPM formal yet accessible to systems engineers and other 
stakeholders, enabling them to be involved through modelling from the early stages of 
requirements formulation. 

The main disadvantage of this approach is the non-standard diagram notation, 
which has similar properties to the Data Flow Diagram (DFD). Another disadvantage 
is a low correlation between modeled process diagrams and their subsequent 
implementation. 


2.2 Rational Unified Process 

The Rational Unified Process (RUP) [7] is an iterative software development process 
framework created by the Rational Software Corporation, a division of IBM since 
2003. RUP is not a single concrete prescriptive process, but rather an adaptable 
process framework, intended to be tailored by the development organizations and 
software project teams that will select the elements of the process that are appropriate 
for their needs. 

The main disadvantage of RUP methodology is that business process analysis is 
used only at the beginning in order to create business requirements. The final 
application reflects the business processes, but there is not created a closer bond with 
them. Therefore, even a small change of business process leads to a fundamental 
change of the created information system. 



2.3 Methodology for Modelling and Analysis of Business Process 

Methodology for Modelling and Analysis of Business Process (MMABP) [6] is based 
on the fact that a business process model is next to an object model one of the two key 
assumptions of the information system global model. Both of these models form the 
basis of a business world general model. The object model is a static model of reality. 
In contrast, a process model is dynamic, and therefore describes the transition from 
initial to final states of the process. 

The advantage of this approach is the use of BPMN for process diagrams and 
Class diagram (UML) for describing objects. The disadvantage of this methodology is 
its focus on process analysis and modelling. The methodology therefore does not 
cover the entire business process life-cycle. 


2.4 Business Driven Development 

Services-Oriented Architecture (SOA) provides an IT framework along with a set of 
principles and guidelines to create IT solutions as a set of reusable, composable, and 
configurable services that are independent of applications and runtime platforms. 
Transitioning an enterprise to SOA requires a Business Driven Development (BDD) 
approach that uses business goals and requirements to drive downstream design, 
development, and testing [5], It brings a much needed flexibility in enterprise IT and 
helps to align IT solutions with business needs. 

It is one of the best so far described methodologies from the view of the close 
interdependence to the business processes. But there is missing the application of a 
workflow reference model that allows to deploy the modelled process instance 
directly to the workflow engine. 


3 Process Oriented Methodology 

The created process-oriented methodology is based on the above mentioned 
methodologies but also eliminates their disadvantages. This innovative methodology 
is described in terms of different phases, from which it is composed, as well as in 
terms of responsible user roles and work products generated by this methodology. 


3.1 Phases 

The first phase of the methodology is Identifying. It tries to define the main strategic 
objectives of the organization. In accordance with the objectives the processes that 
bring added value to the organization are identified, directly or indirectly. 
Accordingly, these processes can be divided into primary’, support and management 
processes [2], It is also appropriate to assign responsibility for individual processes 
and particular activities as well. It is appropriate to use the Use Case Diagram to 
integrate the processes and user roles. The output of the phase is a list of business 
requirements (more details are in the section 3.3). It is convenient to define the 



Glossary to better understand the area of interest, which facilitates communication 
between user roles. The last tasks of the phase are verification and validation of 
business requirements. 

In the Modelling phase , the business process is in detail modelled and decomposed 
into several levels, depending on its complexity. During this phase the emphasis is on 
the correct data flow in processes. Decision-making in processes are solved by using 
business rules, which could be changed during the process runtime. Designed process 
should be simulated in this phase. Simulation can reveal bottlenecks in the process 
and also visualize the process functions. The outcome of this phase is the system 
requirements determination that are in accordance with business requirements. 
System requirements should be approved by the user-validation. One of the key 
elements in this phase is the appropriate automation level determination. 

Configuration is the third phase and deals with a detailed set up of business 
processes. Processes are transformed from the modelling phase into the configuration 
phase mostly in BPEL. In this form they are accompanied by the necessary 
functionality build on service-oriented architecture. Processes consist of already 
existing services or of the brand new ones that need to be programmed. In this phase 
are created the key performance indicators that are intended for the process 
performance control during the runtime. In such way the comprehensive application is 
built on business process. Its instances can be deployed on the workflow engine. The 
created system is set to the end customer. The service and process testing, as well as 
system validation with respect to the system requirements belong to the control 
mechanisms of this phase. 

Execution/Monitoring phase provides primarily two activities. First it is an 
administration of running process instances in the workflow engine. That allows the 
end users to effectively work with the processes. Created applications can be set up 
and configured during the runtime. Business rules enable the configuration of the 
branching in processes, which enables better response to possible changes in a 
company. Setting user rights and roles is another option. Roles and rights can be 
assigned or removed for the current or new users, according to their current 
responsibilities. This phase is also responsible for process monitoring and for 
gathering data about process run. Based on this information, it is possible to evaluate 
the process progress and partly adapt the process on the flow. Defined KPIs have a 
great impact. They enable overall control of the process and therefore also a rapid 
response to sudden changes. 

The last phase is Optimization. This phase is crucial for continuous process 
improvement. During the monitoring phase the data about process instances are 
collected, which may result in some gaps in the modelled process. There are some 
advanced techniques of mathematical statistics or process mining available for the 
process instances analysis. Based on the results it is possible to choose two different 
approaches to process improvement. It is a Business Process Reengineering (BPR) or 
a Total Quality Management (TQM) [6], TQM is focused on the consequent 
improvement of processes. On the other hand, BPR focuses on radical changes. 
According to the chosen approach, new specification of business processes is created. 



3.2 Roles 


Stakeholder represents interest groups whose needs must be satisfied by the project. It 
is a role that may be played by anyone who is (or potentially will be) materially 
affected by the outcome of the project. 

Business analyst is a high-level role responsible for the business analysis and BPM 
work activities. The business analyst performs process modelling and creates 
functional specifications for process. This high-level role implies that the analyst 
might also take on more specialized tasks during the project. 

Architect is a high-level role responsible for the overall work effort of creating the 
architecture and design of the system. More specialized roles, such as enterprise 
architect, application architect, SOA architect, and infrastructure architect, are 
actually responsible for various architectural work efforts that constitute the design 
phase of the project. 

Developer is a high-level role responsible for the implementation of the solution 
(services). 

Tester is a role responsible for performing activities required to test the application 
before it is deployed into a production environment. 

Line Manager is a person who heads revenue generating departments 
(manufacturing and selling) and is responsible for achieving an the organization's 
main objectives by executing functions such as policy making, target setting, decision 
making. 


3.3 Work Products 

This section describes the outputs generated by the methodology. Thus outputs are 
quite a bit through the methodology phases and therefore only main outcomes of the 
various phases are described. 

Business Requirements are requirements based on customer's wishes and their 
needs. They describe the principles and functioning of a company as a whole, 
defining its objectives [7]. Identified processes are part of these requirements. 

System Requirements are the modeling phase results. These are the requirements 
for creating an information system built on business processes. Detailed and 
hierarchically organized process diagrams are part of this output. These requirements 
also describe the level of process automation. 

Information System is a result of the configuration phase. Modeled processes are 
configured and composed of individual services. Thus created processes are deployed 
on a process engine, which interprets them. The workflow engine also allows 
interaction with users and external tools. 

Monitoring data is an output of the monitoring phase. It contains information about 
process instances run, such as duration or cost of individual processes. It also records 
the passage through the business process, which can be useful in further analysis. 

Strategic plans are the optimization phase outputs. The overall technology 
improvement (TQM, BPR) and strategic plans for further business process 
improvement are chosen in strategic plans. 



4 Recommendations for Emergency Management 


In case the methodology is used in the field of emergency management it is 
appropriate to consider certain features that arise from this specific area. This includes 
clearly defined organizational structure, legislative and other issues. Some features 
are illustrated on emergency management in the Czech Republic. 


4.1 Organizational Structure 

The Integrated Rescue System (IRS) is determined for co-ordination of rescue and 
clean-up operations in case, where a situation requires operation of forces and means 
of several bodies, e.g. fire fighters, police, medical rescue service and other bodies, or 
in case, where the rescue and clean-up operation is necessary to be co-ordinated from 
the Ministry of Interior or by a leader of region’s level, or by mayors of municipalities 
with extended responsibilities [4], As the Integrated Rescue System are therefore 
considered the co-ordinated proceedings of its bodies during preparations for 
emergencies, and during rescue and clean-up operations. 

As permanent authorities for coordination of Integrated Rescue System bodies are 
considered the operational and information centres of the Integrated Rescue System, 
i.e. the operational centres of regional Fire Rescue Services and the Operational and 
Information Centre of the General Directorate of the Czech Fire Rescue Service. 


4.2 Legislation and Documentation 

There are many laws dealing with emergency management in the Czech Republic. 
Crisis management elements are codified in the Law No. 240/2000 on crisis 
management and on modification of certain codes (Crisis Code), in latter wording. 
Based on this law, state of danger can be proclaimed to overcome unfavourable trends 
of development. The other important Law is the Law No. 239/2000 on the Integrated 
Rescue System and on amendment of certain codes, in latter wording, is the basic 
legal frame describing situation around IRS. 

Another feature of the emergency management is the detailed documentation that 
defines how to proceed in particular situations. The Contingency Plans belong to the 
basic documents. They contain a set of measures and procedures addressed to crisis 
situations, i.e. they contain sum of planning, methodological and informational 
documents used in decision-making, management and coordination of tasks in the 
emergencies. 


4.3 Different Types of Information 

To deal successfully with critical situations, it is inevitable for all IRS components to 
have all the necessary information at their disposal. It is often not trivial because the 
information used in emergency management can have three basic characteristics or 
dimensions: time, space and aggregation. The time dimension of the data is important 



in the crisis situation with dynamic character. It could be contamination spreading or 
the direction of wind during the fire fighting. This information varies with time so it is 
a relevant factor in dealing with the crisis situation. Another important aspect of the 
information is that it is bound to the intervention place. It is only the limited area 
around the intervention place that is important and it can be defined according to the 
character of the crisis. The last dimension of information relevant to dealing with a 
crisis situation is aggregation. The data is provided to the intervention units in 
aggregated form, for example as specific maps or map layers. However, they contain 
also specific data sets that could be irrelevant to the character of a particular 
intervention location or to the crisis itself. The way to avoid unnecessary information 
is to use adaptive mapping [3], 


4.4 Psychological Aspects 

There is a new belief that even despite the devastating impact of disasters, substantial 
lack of resources, and general chaos, there is still a possibility of carrying out some 
actions that will serve in maintaining at least the basic integrity of the human society 
and its dignity. Psychological aspects are usually very important for dealing with 
crises. All activities of crisis management are performed under substantial time and 
psychological pressure. Intervention commanders work and make decisions in fear of 
their possible failure. They often have insufficient and inaccurate information at their 
own disposal during chaotic development of the situation. Other problems arise from 
lack of necessary resources, like working tools and necessary equipment or integrated 
rescue system resources. The basic requirements of life may sometimes be restricted 
under the influence of all these factors. 


4.5 Using of Standards 

Unified Modelling Language (UML) is a standardized modelling language used in the 
field of software engineering. Two diagrams are suitable for process modelling. One 
of them is Use Case Diagram , which shows the functionality provided by the system 
in terms of actors, their goals represented as use cases. Then it depicts all the relations 
among those use cases. The other is Activity Diagram. It represents the business and 
operational step-by-step workflows of components in a system. 

Business Process Modelling Notation (BPMN) provides a notation that is 
understandable by all business users, from the business analysts that create the initial 
drafts of the processes, to the technical developers responsible for implementing the 
technology that will perform those processes, and finally also the business people who 
will manage and monitor those processes. This way, BPMN creates a standardized 
bridge over the gap between the business process design and process implementation. 

Web Services Business Process Execution Language (WS-BPEL) defines a model 
and a grammar for describing the behaviour of a business process based on 
interactions between the process and its partners. The WS-BPEL process defines how 
multiple service interactions with these partners are coordinated to achieve a business 
goal, as well as the state and the logic necessary for this coordination. 



5 Conclusions 


The primary contribution of this paper is the innovative, process-oriented 
methodology. The methodology is described in terms of phases, user roles and work 
products. The paper also describes the set of recommendations, which should be 
applied when methodology is used on emergency management processes. 
Recommendations are based on practical experiences with solving of the research 
plan called Dynamic Geovisualisation in Crises Management [3] [4]. The research 
plan also illustrates the practical use of the methodology in real situations, for 
example in accidents with dangerous substances. 

It is appropriate to emphasis on adequate software support during the methodology 
use. This support is provided by Business Process Management Suite (BPMS), where 
different tools support different methodology phases. In case of a comprehensive 
emergency management system it is necessary to take the close interoperability to 
GIS or other operational systems used by the IRS into account. Therefore it is 
recommended to add the global architecture which will illustrate the overall 
deployment of the system based on business processes. 

The subsequent objective of this research is to define in detail the methodology 
phases in terms of individual tasks and their links to each other. This is related to the 
assignment of responsibilities for these tasks. Similarly, detailed description of the 
role associated with implementing the methodology in terms of ICT and EM is 
needed. The final aim is to describe in detail the tasks inputs and outputs in terms of 
work products and determine whether all information is available at the right time. 
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